As more and more folks start turning to SharePoint as their solution of choice for information distribution and collaboration, I have been noticing that many of these installations seem to have been quick, no research installations. A number of these installations suffer from common mistakes that are then made by well intentioned, but over-worked and under trained Administrators. In an effort to help stem the tide and perhaps save one or two of you the trouble of having to redeploy SharePoint in an effort to fix an unsuccessful roll-out I'd like to take a trip back to the basics.
First of all, if you are reading this then you are indeed a step ahead of those who did not take the time to do at least a little bit of research on how to properly deploy SharePoint before inserting the CD and hitting OK. With a little planning and forethought you can avoid many of the common mistakes that plague the first time install.
Step 1: Do not use your own personal account when installing SharePoint onto your servers. The account that is used to do the actual binary installation of the SharePoint files is going to own those files and have certain privileged access that, for tighter security, really shouldn't be your user account. Furthermore, do not use a local user account, the local system account or a network system account for the installation of SharePoint binaries on your servers. SharePoint can scaled out into a distributed server deployment and local accounts simply will not provide you the access rights you'll between servers. For this part you are going to want to create a basic user account in your Active Directory domain that you will use for the installation process. This account does not need to be a Domain Administrator, an Enterprise Administrator or even a Server Admin. It simply needs to be a member of the local Administrators group on your SharePoint Server systems. In addition to this you also need to grant the account DB Creator and Security Admin rights on the SQL server that will function as the back end database for your SharePoint deployment. That's it.
Step 2: When performing the installation you will be presented with a couple of different options. the first of these choices will be to select between a Basic or an Advanced installation. This one is easy, always choose Advanced. Always. A Basic install will use SQL Express on the local system as your database and therefore limit the size of your SharePoint deployment. Also, you will not be able to expand your Basic install in the future by adding additional servers should you want to grow your SharePoint farm. The next option you will be presented with will the type of server installation to perform for your Advanced choice. These options include Complete, Web Front End and a Single Server install. Guess what, this really isn't much of a choice either. Always perform a Complete installation. Always. The Single server option is the same as the Basic option from the previous screen and so has the same limitations. Choosing the Web Front End option will limit your flexibility in the future if you should want, or need, to move roles between servers, or worse, need to compensate for a failed system. Save yourself from future headaches and just perform an Advanced>Complete installation every time.
Step 3: Once you have installed SharePoint, making sure you used the account you created in step 1, you will then run the SharePoint Products and Technologies Configuration Wizard. This is where you will actually create your Farm and establish your Central Administration Web Application. During this process the wizard will prompt you for the Database Server, Database Name and the credentials of an account that will be used for the Central Administration Application Pool. At this point you should once again supply the credentials of the account that you just used to actually perform the installation, the one you are currently logged onto the machine as running this very wizard. Yup, the installation account and the Central Administration service account really should be using the same account. This will help you down the road if these two accounts are indeed the same account. It has been my experience that when using different accounts for these two functions, odd behaviors can creep up in your SharePoint world.
Following these few simple steps can save you a number of headaches down the road while working with SharePoint and help get you off on the right foot. I realize that many over-stressed network folks simply don't have the time to get any proper training before having to roll out a product such as SharePoint. Still, before you get to deep into such a project I highly recommend that you at least grab yourself a good book to keep by your side while deploying. One such tome I feel should be by the side of every SharePoint Administrator is the SharePoint Best Practices book by Ben Curry and Bill English.
Until next time...